Efficient compressed track size classification to reduce disk fragmentation and increase probability of in-place compressed writes

ABSTRACT

In a data storage system in which a full-size allocation unit is used for storage of uncompressed data, an optimal reduced size allocation unit is selected for storage of compressed data. Changes in the compressed size of at least one full-size allocation unit of representative data are monitored over time. The representative data may be selected based on write frequency, relocation frequency, or both. Compression size values are counted and weighted to calculate the optimal reduced allocation unit size. The optimal reduced size allocation unit is used for storage of compressed data. A full-size allocation unit of data that cannot be accommodated by a reduced size allocation unit when compressed is stored uncompressed.

TECHNICAL FIELD

The subject matter of this disclosure is generally related to datastorage systems and more particularly to storage of compressed data.

BACKGROUND

High capacity data storage systems such as storage area networks (SANs)are used to maintain large data sets and contemporaneously supportmultiple users. A SAN includes a network of interconnected compute nodesthat manage access to arrays of drives. The compute nodes respond toinput-output (IO) commands from host applications that typically run onclustered servers (aka “hosts”). Examples of host applications mayinclude, but are not limited to, software for email, accounting,manufacturing, inventory control, and a wide variety of other businessprocesses.

SANs and other types of high capacity data storage systems typicallycompress some of the data stored on the managed drives. For example,host application data that is relatively infrequently accessed by thehosts may be compressed in order to reduce storage capacityrequirements. Host application data that is relatively frequentlyaccessed may be stored uncompressed so that is can be accessed with lowlatency. Although data compression tends to reduce storage capacityrequirements there are potential drawbacks such as the need to relocateupdated compressed data that compresses to a larger size and istherefore unable to be stored at its existing location.

SUMMARY

All examples, aspects and features mentioned in this document can becombined in any technically possible way.

In accordance with some implementations an apparatus comprises: a datastorage system comprising: a plurality of compute nodes interconnectedwith a plurality of drives; at least one storage object on which data islogically stored, the storage objects being backed by the drives; and acompressed data manager that selects at least one full-size allocationunit of representative data, monitors changes in compressed size of thefull-size allocation unit of representative data over time, selects areduced size allocation unit for compressed data based on the changes incompressed size of the full-size allocation unit of representative dataover time, and causes the compute nodes to use both the full-sizeallocation unit and the reduced size allocation unit for storage of dataon the drives. In some implementations the storage system uses only onereduced size allocation unit for storage of compressed data. In someimplementations the compressed data manager weights values of themonitored compressed size. In some implementations the compressed datamanager weights the values of the monitored compressed size usingweights W=Bucket Size Counter Value*(Bucket Size/100)^(P), where P is ahyper parameter. In some implementations the compressed data managerselects at least one full-size allocation unit of representative databased on frequency of write operations. In some implementations thecompressed data manager selects at least one full-size allocation unitof representative data based on frequency of relocation operations. Insome implementations the compressed data manager selects a new reducedsize allocation unit for compressed data based on changes in averagecompressed size of full-size allocation units of data.

In accordance with some implementations a method comprises: selecting atleast one full-size allocation unit of representative data; monitoringchanges in compressed size of the full-size allocation unit ofrepresentative data over time; selecting a reduced size allocation unitfor compressed data based on the changes in compressed size of thefull-size allocation unit of representative data over time; and usingboth the full-size allocation unit and the reduced size allocation unitfor storage of data. Some implementations comprise using only onereduced size allocation unit for storage of compressed data. Someimplementations comprise weighting values of the monitored compressedsize. Some implementations comprise calculating a weight W=Bucket SizeCounter Value*(Bucket Size/100)^(P), where P is a hyper parameter. Someimplementations comprise selecting based on frequency of writeoperations. Some implementations comprise selecting based on frequencyof relocation operations. Some implementations comprise selecting a newreduced size allocation unit for compressed data based on changes inaverage compressed size of full-size allocation units of data.

In accordance with some implementations a computer-readable storagemedium stores instructions that when executed by a computer cause thecomputer to perform a method for using a computer system to implementmultiple allocation units for storage of data, the method comprising:selecting at least one full-size allocation unit of representative data;monitoring changes in compressed size of the full-size allocation unitof representative data over time; selecting a reduced size allocationunit for compressed data based on the changes in compressed size of thefull-size allocation unit of representative data over time; and usingboth the full-size allocation unit and the reduced size allocation unitfor storage of data. Some implementations comprise using only onereduced size allocation unit for storage of compressed data. Someimplementations comprise weighting values of the monitored compressedsize. Some implementations comprise selecting based on frequency ofwrite operations. Some implementations comprise selecting based onfrequency of relocation operations. Some implementations compriseselecting a new reduced size allocation unit for compressed data basedon changes in average compressed size of full-size allocation units ofdata.

Other aspects, features, and implementations will be apparent in view ofthe detailed description and figures.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a storage array with a compressed track manager thatperforms compressed track size classification and selects an optimaltrack size for compressed data based on that classification.

FIG. 2 illustrates processing of a write IO by the storage array of FIG.1.

FIG. 3 illustrates hierarchical data structures of the storage arraythat relate the managed drives to a production volume.

FIG. 4 illustrates raw compressed track size classification.

FIG. 5 illustrates weighted compressed track size classification.

FIG. 6 illustrates implementation of a selected optimal track size forcompressed data.

FIG. 7 illustrates steps associated with operation of the compressedtrack manager.

DETAILED DESCRIPTION

The terminology used in this disclosure is intended to be interpretedbroadly within the limits of subject matter eligibility. The terms“disk” and “drive” are used interchangeably herein and are not intendedto refer to any specific type of non-volatile storage media. The terms“logical” and “virtual” are used to refer to features that areabstractions of other features, e.g. and without limitation abstractionsof tangible features. The term “physical” is used to refer to tangiblefeatures that possibly include, but are not limited to, electronichardware. For example, multiple virtual computers could operatesimultaneously on one physical computer.

Some aspects, features, and implementations described herein may includemachines such as computers, electronic components, optical components,and processes such as computer-implemented procedures and steps. It willbe apparent to those of ordinary skill in the art that thecomputer-implemented procedures and process steps may be stored ascomputer-executable instructions on a non-transitory computer-readablemedium. Furthermore, it will be understood by those of ordinary skill inthe art that the computer-executable instructions may be executed on avariety of tangible processor devices, i.e. physical hardware. Forpractical reasons, not every step, device, and component that may bepart of a computer or data storage system is described herein. Those ofordinary skill in the art will recognize such steps, devices, andcomponents in view of the teachings of the present disclosure and theknowledge generally available to those of ordinary skill in the art. Thecorresponding machines and processes are therefore enabled and withinthe scope of the disclosure.

FIG. 1 illustrates a storage array 100 with a compressed track manager102 that performs compressed track size classification and selects anoptimal track size for compressed data based on that classification. Thestorage array is one example of a SAN, which is one example of a datastorage system in which the compressed track manager could beimplemented. Storage arrays and other types of SANs use differentallocation units for internal and external IOs, where an allocation unitdefines a fixed amount of storage capacity. It is a common designfeature for a storage array to use only a single allocation unit forinternal IOs in order to facilitate management of metadata. However,reliance on a single allocation unit can result in creation offragmented “saved space” when data compression is implemented. Forexample, if the single internal allocation unit is a 128K track, andtracks of data that are compressed are compressed/decompressedindependently, then each 128K track of storage in which compressed datais stored includes less than 128K of contiguous saved space. That savedspace is typically non-contiguous with the saved space of the adjacenttracks so use of those small non-contiguous saved spaces tends topromote fragmentation. The aggregate amount of non-contiguous savedspace can be reduced at the cost of somewhat more complex metadatamanagement by using multiple reduced size allocation units of storagecapacity for compressed data. For example, a storage system may usefull-size 128K tracks to store uncompressed data and maintain pools ofsmaller reduced size tracks, e.g. 64K, 32K, and 8K tracks, for storingcompressed data. Efficiency is increased by selectively using thereduced size track that most efficiently accommodates the compresseddata on a per-track basis, e.g. storing a 128K track of uncompresseddata that compresses to 30K in a 32K track and storing a 128K track ofuncompressed data that compresses to 6K in a 8K track. However, theincrease in efficiency may be partially offset by increased frequency ofdata relocation. Data is changed in response to write commands from thehosts. Each write TO may increase or decrease the compressed size of thedata. For example, a 128K track that initially compresses to 8K mightonly compress to 32K after a first write and at some future time after asubsequent write only compress to 64K. As a result, data may need to berelocated frequently to different ones of the reduced sized tracks. Theoverhead associated with data relocation tends to offset or reduce thebenefits of enhanced efficiency associated with using multiple reducedsize allocation units of storage capacity. As will be discussed ingreater detail below, the compressed track manager helps to solve theproblem and improve performance of the storage array by performingcompressed track size classification to select an optimal track size forcompressed data stored on a storage object. For example, the optimaltrack size for compressed data may be the only reduced size track thatis implemented by the storage system for a selected storage object.

The storage array 100 depicted in a simplified data center environmentin FIG. 1 supports two network server hosts 103 that run hostapplications. The hosts 103 include volatile memory, non-volatilestorage, and one or more tangible processors. The storage array 100includes one or more bricks 104. Each brick includes an engine 106 andone or more drive array enclosures (DAEs) 108, 110. Each engine 106includes a pair of interconnected compute nodes 112, 114 that arearranged in a failover relationship and may be referred to as “storagedirectors.” Although it is known in the art to refer to the computenodes of a SAN as “hosts,” that naming convention is avoided in thisdisclosure to help distinguish the network server hosts 103 from thecompute nodes 112, 114. Nevertheless, the host applications could run onthe compute nodes, e.g. on virtual machines or in containers. Eachcompute node includes resources such as at least one multi-coreprocessor 116 and local memory 118. The processor may include centralprocessing units (CPUs), graphics processing units (GPUs), or both. Thelocal memory 118 may include volatile media such as dynamicrandom-access memory (DRAM), non-volatile memory (NVM) such as storageclass memory (SCM), or both. Each compute node includes one or more hostadapters (HAs) 120 for communicating with the hosts 103. Each hostadapter has resources for servicing input-output commands (IOs) from thehosts. The host adapter resources may include processors, volatilememory, and ports via which the hosts may access the SAN. Each computenode also includes a remote adapter (RA) 121 for communicating withother storage systems such as storage array 123. Each compute node alsoincludes one or more drive adapters (DAs) 128 for communicating withmanaged drives 101 in the DAEs 108, 110. Each drive adapter hasprocessors, volatile memory, and ports via which the compute node mayaccess the DAEs for servicing IOs. Each compute node may also includeone or more channel adapters (CAs) 122 for communicating with othercompute nodes via an interconnecting fabric 124. The managed drives 101include non-volatile storage media such as, without limitation,solid-state drives (SSDs) based on EEPROM technology such as NAND andNOR flash memory and hard disk drives (HDDs) with spinning disk magneticstorage media. Drive controllers may be associated with the manageddrives as is known in the art. An interconnecting fabric 130 enablesimplementation of an N-way active-active backend. A backend connectiongroup includes all drive adapters that can access the same drive ordrives. In some implementations every drive adapter 128 in the SAN canreach every DAE via the fabric 130. Further, in some implementationsevery drive adapter in the SAN can access every managed drive 101 in theSAN.

Data (i.e. host application data) associated with the host applicationinstances running on the hosts 103 is maintained on the managed drives101. The managed drives 101 are not discoverable by the hosts 103 butthe storage array 100 creates storage objects such as production volume140 that can be discovered and accessed by the hosts. A productionvolume is a logical storage device that may be referred to as aproduction device or production LUN, where “LUN” refers to the logicalunit number used to identify logical storage volumes in accordance withthe small computer system interface (SCSI) protocol. From theperspective of the hosts 103, the production volume 140 is a singledrive having a set of contiguous fixed-size logical block addresses(LBAs) on which data used by the instances of the host applicationresides. However, the host application data is physically stored atpotentially non-contiguous addresses on various managed drives 101. Inother words, the production volume is an abstraction layer between thehosts and the managed drives.

Referring to FIG. 2, each compute node (e.g. computer node 112) of thestorage array dedicates a portion or partition of its respective localmemory to a logical shared memory 200 that can be accessed by othercompute nodes of the storage array, e.g. via direct memory access (DMA).A first portion 204 of the shared memory 200 is dedicated for storingmetadata. A second portion 212 of the shared memory 200 is dedicated forstoring production volume data. Fixed size metadata pages 206 in thefirst portion 204 include track identifications (TIDs) that indicate,among other things, where associated tracks of production volume dataare located in the second portion 212 of the shared memory and themanaged drives 101. Selected tracks 214 of the production volume dataare copied from the managed drives 101 into the second portion 212 ofthe shared memory to service IOs. Tracks of data that are no longerrequired are destaged from the shared memory to the managed drives or,alternatively, flushed from the shared memory if the track data in theshared memory is redundant with the corresponding track data on themanaged drives.

In response to an IO command 216 sent by a host 103 to write data to theproduction volume 140, compute node 112 uses a hash table 220 to obtainthe page numbers 222 of the metadata pages 206 associated with the LBAsbeing written. Specifically, the device number, cylinder number, head,and size specified in the IO command are inputted to the hash table. Thepage numbers resulting from the lookup are used to find correspondingpages of metadata in the first portion 204 of the shared memory 200. TheTIDs in those metadata pages are used to find and obtain thecorresponding tracks of data in the second portion 212 of the sharedmemory. If the tracks associated with those TIDs are not in the sharedmemory, then those tracks are copied into the shared memory from themanaged drives. After the data being written by the IO 216 is copiedinto the tracks 214 of the shared memory and the corresponding TID hasbeen updated then an ACK 218 is sent from the compute node 112 to thehost 103 to indicate that the write IO 216 has been processed. Theupdated data track is subsequently destaged to the managed drives 101 inthe background using an internal write IO 216′. The data may be writtenas uncompressed track data or compressed track data. Write IO 216′differs from write IO 216 because a track is used as the allocation unitrather than blocks.

FIG. 3 illustrates hierarchical data structures of the storage arraythat relate the managed drives 101 to the production volume 140 viamultiple abstraction layers. The smallest unit of storage capacity thatcan be processed by a managed drive 101 is a sector 300. Different typesof managed drives may be characterized by different sector sizes but forcontext and without limitation the sector size of all managed drive inthe illustrated example is 2K. The managed drives 101 are each mappedinto logical splits 301 of equal capacity. Each split includes acontiguous range of logical addresses. Selection of split storagecapacity is a design implementation and, for context and withoutlimitation, may be some fraction or percentage of the capacity of amanaged drive equal to an integer multiple of sectors greater than 1.Groups of splits 301 from multiple managed drives are used to createdata devices (TDATs) 303. The splits on each TDAT are organized asmembers of a RAID protection group. A storage resource pool 305, alsoknown as a “thin pool,” is a collection of TDATs 309, 311, 313, 315, 317of the same emulation and RAID protection type. In some implementationsall TDATs in a drive group are of a single RAID protection type and allare the same size (storage capacity). Different TDATs in the storageresource pool may be mapped for different track sizes. For example, TDAT309 may have 8K sized tracks, TDAT 311 may have 16K sized tracks, TDAT313 may have 32K sized tracks, TDAT 315 may have 64K sized tracks, andTDAT 317 may have 128K sized tracks. Logical thin devices (TDEVs) 319,321, 323 are created using TDATs. The TDEVs implement only the full-size(largest) track size, e.g. 128K. Multiple TDEVs are organized into astorage group 325. The production volume 140 is created from a singlestorage group 325.

Host application data, which is stored in blocks on the productionvolume 140, is mapped to tracks of the TDEVs. A full-size track, whichis an allocation unit of 128K capacity in the illustrated example, islarger than the fixed size blocks used in communications between thestorage array and the hosts to access the production volume. Compressedtracks are initially stored on full-size tracks or on any of a varietyof different reduced sized tracks selected based on comparison ofcompressed track size and implemented track size. For example, a 128Kuncompressed track of a TDEV that compresses to 10K may be stored onTDAT 311 because the 16K reduced size tracks implemented on TDAT 311 arethe closest track size larger than 10K. However, as will be explainedbelow, the track sizes implemented by the TDATs and/or used forcompressed data are adjusted based on compressed track sizeclassification once an optimal track size for compressed data has beendetermined.

Raw compressed track size classification for a storage object isdetermined based on one or more representative uncompressed (e.g., 128K)tracks on the storage object. In the illustrated example a group ofblocks/LBAs 329 of the production volume 140 corresponding to a 128Ktrack 327 on TDEV 319 are selected to represent the storage array and/orproduction volume and/or TDEV. The representative blocks/LBAs may beselected based on activity level and compression state. For example, andwithout limitation, the blocks/LBAs on the production volume that havebeen most frequently written within a recent time window and stored ascompressed data may be selected to represent the entire productionvolume.

One technique for selecting representative tracks from tracks that arebeing frequently written and compressed is to build a track levelheatmap of data relocation. Data relocation statistics may be maintainedfor each storage group. Storage groups are ranked based on datarelocation rate. One or more of the storage groups of the storage arraymay be selected based on the storage group rankings. TDEVs within eachselected storage group may be ranked based on data relocation rate, e.g.using relocation counts represented within shared memory between hostadapter emulation, data service emulation and disk adapter emulation.One or more TDEVs having the greatest relocation rate are selected andrepresentative tracks within the selected TDEVs are selected based onranked relocation rate. For each selected TDEV, K-means auto clusteringmachine learning algorithms are used to build 10 (or N) clusters basedon incoming host IO logical block addresses. The top few (M) clusterscharacterized by a high density of IO's are selected. Each track inthese top M clusters are selected for data analysis. P number ofconsecutive tracks nearby to this selected track are also chosen forfurther data analysis due to locality of reference. TO relocationstatistics are also maintained at chunk level and each chunk is made upof P number of consecutive tracks. We rank these chunks in a time windowT and pick the top (M number of) chunks which has high TO relocationcounts for data analysis. Each track is choosen in a given chunk forfurther data analysis.

Referring to FIG. 4, each selected representative track is monitored fora predetermined amount of time to generate a statistical representationof changes in compressed track size over time. For example, buckets thatrepresent compressed sizes of the representative track in 1K incrementsor increments corresponding to possible track sizes such as 8K, 16K, 32Ketc. may be created. Counts are maintained for each bucket. Each timethat the representative track is changed by a write in the predeterminedtime period, compressed and stored, the count of the bucket having asize corresponding to the compressed track size is incremented. Forexample, when the representative track compresses to 64K following awrite then the count of the 64K bucket is incremented. The countingstops when some predetermined condition is satisfied, e.g. elapsed time.In the illustrated example final counts of 10, 20, 30, 45, and 40 wererespectively recorded in buckets of sizes 8K, 16K, 23K, 64K, and 96K(not all of the buckets in 1K increments are shown) for a singlerepresentative track.

The bucket with the greatest final raw count could be selected asindicating the optimal size for compressed tracks of the storage array,production volume or TDEV. However, the bucket having the greatest rawcount is not necessarily indicative of the optimal track size forcompressed data. In the illustrated example a significant count(count=40) was recorded in the 96K size bucket although the 64K sizebucket count (count=45) was greater. The relatively high final count ofthe 96K bucket suggests that a potentially significant amount of datawould be relocated due to the compressed size of tracks exceeding 64K.Weighting can be used to help alleviate this situation whilediscriminating between buckets with significant counts and outliers.

FIG. 5 illustrates weighted compressed track size classification. Theweight for each bucket is directly proportional to its compressed sizemultiplied by the bucket count. For example, the weight (W) may becalculated as W=Bucket Size Counter Value*(Bucket Size/100)^(P), where Pis a hyper parameter (W for each bucket is calculated using the samevalue of P). For example, and without limitation, P can be any valuebetween 1 to N (by default it is 1). Referring to the illustratedexample, the 8K sized bucket has a counter value 10 so the weight W is10*8=80 for P=1. The weighted count of a bucket is equal to the rawcount multiplied by the bucket weight so the weighted value of the 8Ksized bucket in the illustrated example is 10*8=80. The weighted countof the 16K sized bucket is 20*16=320 The weighted count of the 23K sizedbucket is 30*23=690 The weighted count of the 64K sized bucket is45*64=2880. The weighted count of the 96K sized bucket is 40*96=3840.The weighted count 3840 of the 96K size bucket is greater than theweighted count 2880 of the 64K size bucket so the optimal size forcompressed tracks in accordance with the weighted compressed track sizeclassification is 96K. Outliers such as low count buckets representinglarger compressed track sizes result in relatively small weights andtherefore do not generate the greatest weighted count. Increasing thevalue of P reduces relocation cost by more greatly weighting larger IOsizes. Thus, a desired balance between optimal track size efficiency andrelocation cost may be implemented by selecting an appropriate value ofP.

Referring to FIG. 6, responsive to selection of 96K as the optimal tracksize for compressed data, selected TDATs 309, 311, 313, 315 in thestorage resource pool 305 may be updated to implement the selectedoptimal track size of 96K. In some implementations all TDATs that willbe used to store compressed data are updated to implement only theselected optimal track size. Tracks of production volume data thatcompress to 96K or less (and are designated for storage in compressedform) in the illustrated example are stored on size 96K tracks. Tracksof production volume data that compress to greater than 96K are storedon size 128K tracks. Specifically, the tracks that compress to greaterthan 96K may be stored uncompressed. By calculating and using theselected optimal track size for compressed data as described above, therate of data relocation is reduced relative to using multiple closelysize-spaced allocation units as shown in FIG. 3 while reducingfragmentation relative to using only a single allocation unit.Consequently, disk fragmentation is reduced while the probability ofin-place compressed write operations is increased.

There may be situations in which use of a single value of P producesskewed results. For example, similarly sized Write IOs in closely spacedbursts might dominate samples. In such situations different values of Pmay be used for one or more of the buckets. For example, the weight forthe 8K bucket size may be calculated as W=Bucket Size CounterValue*(Bucket Size)^(X), the weight for the 16K bucket size may becalculated as W=Bucket Size Counter Value*(Bucket Size)^(Y), and theweight for the 96K bucket size may be calculated as W=Bucket SizeCounter Value*(Bucket Size)^(Z), where X, Y and Z are different valuesof the exponent P.

There may be situations in which in-place writes become undesirable,such as when a host application software upgrade causes the size of newWrite IOs to change significantly. For example, a host may implement 16k sized new Writes in-place to 96 k sized optimal tracks that wereselected based on prevalence of 64K sized new Writes before the hostapplication software upgrade. A virtual provisioning layer may tracksuch changes and trigger selection of a new optimal track size forcompressed data. The TDATs are then updated to implement the newlyselected optimal track size for compressed data.

FIG. 7 illustrates operation of the compressed track manager.Representative tracks are selected as indicated in step 700. Selectionmay be accomplished by generating heatmaps as discussed above, forexample, and without limitation. A representation of the compressed sizeof the representative tracks over time is created as indicated in step702. This may be accomplished using the buckets described above, forexample, and without limitation. Weights are calculated as indicated instep 704. This may be accomplished using the algorithm described above,for example, and without limitation. An optimal track size forcompressed data is selected as indicated in step 706. This may beaccomplished using the weighted counts described above, for example, andwithout limitation. The devices in the storage resource pool are updatedas indicated in step 708. This may be accomplished by implementing onlyfull-size tracks and the optimal reduced size track as described above,for example, and without limitation. Selection of the optimal track sizefor compressed data is repeated on trigger conditions as indicated instep 710. This may be accomplished using the virtual provisioning layeras described above, for example, and without limitation.

Specific examples have been presented to provide context and conveyinventive concepts. The specific examples are not to be considered aslimiting. A wide variety of modifications may be made without departingfrom the scope of the inventive concepts described herein. Moreover, thefeatures, aspects, and implementations described herein may be combinedin any technically possible way. Accordingly, modifications andcombinations are within the scope of the following claims.

What is claimed is:
 1. An apparatus comprising: a data storage systemcomprising: a plurality of compute nodes interconnected with a pluralityof drives; at least one storage object on which data is logicallystored, the storage objects being backed by the drives; and a compresseddata manager that selects at least one full-size allocation unit ofrepresentative data, monitors changes in compressed size of thefull-size allocation unit of representative data over time, selects areduced size allocation unit for compressed data based on the changes incompressed size of the full-size allocation unit of representative dataover time, and causes the compute nodes to use both the full-sizeallocation unit and the reduced size allocation unit for storage of dataon the drives.
 2. The apparatus of claim 1 wherein the storage systemuses only one reduced size allocation unit for storage of compresseddata.
 3. The apparatus of claim 1 wherein the compressed data managerweights values of the monitored compressed size.
 4. The apparatus ofclaim 3 wherein the compressed data manager weights the values of themonitored compressed size using weights W=Bucket Size CounterValue*(Bucket Size/100)^(P), where P is a hyper parameter.
 5. Theapparatus of claim 1 wherein the compressed data manager selects atleast one full-size allocation unit of representative data based onfrequency of write operations.
 6. The apparatus of claim 1 wherein thecompressed data manager selects at least one full-size allocation unitof representative data based on frequency of relocation operations. 7.The apparatus of claim 1 wherein the compressed data manager selects anew reduced size allocation unit for compressed data based on changes inaverage compressed size of full-size allocation units of data.
 8. Amethod comprising: selecting at least one full-size allocation unit ofrepresentative data; monitoring changes in compressed size of thefull-size allocation unit of representative data over time; selecting areduced size allocation unit for compressed data based on the changes incompressed size of the full-size allocation unit of representative dataover time; and using both the full-size allocation unit and the reducedsize allocation unit for storage of data.
 9. The method of claim 8comprising using only one reduced size allocation unit for storage ofcompressed data.
 10. The method of claim 8 wherein selecting the reducedsize allocation unit for compressed data based on the changes in thecompressed size of the basic allocation unit of representative data overtime comprises weighting values of the monitored compressed size. 11.The method of claim 10 wherein weighting the values of the monitoredcompressed size comprises calculating a weight W=Bucket Size CounterValue*(Bucket Size/100)^(P), where P is a hyper parameter.
 12. Themethod of claim 8 wherein selecting at least one full-size allocationunit of representative data comprises selecting based on frequency ofwrite operations.
 13. The method of claim 8 wherein selecting at leastone full-size allocation unit of representative data comprises selectingbased on frequency of relocation operations.
 14. The method of claim 8comprising selecting a new reduced size allocation unit for compresseddata based on changes in average compressed size of full-size allocationunits of data.
 15. A computer-readable storage medium storinginstructions that when executed by a computer cause the computer toperform a method for using a computer system to implement multipleallocation units for storage of data, the method comprising: selectingat least one full-size allocation unit of representative data;monitoring changes in compressed size of the full-size allocation unitof representative data over time; selecting a reduced size allocationunit for compressed data based on the changes in compressed size of thefull-size allocation unit of representative data over time; and usingboth the full-size allocation unit and the reduced size allocation unitfor storage of data.
 16. The computer-readable storage medium of claim15 comprising using only one reduced size allocation unit for storage ofcompressed data.
 17. The computer-readable storage medium of claim 15wherein selecting the reduced size allocation unit for compressed databased on the changes in the compressed size of the basic allocation unitof representative data over time comprises weighting values of themonitored compressed size.
 18. The computer-readable storage medium ofclaim 15 wherein selecting at least one full-size allocation unit ofrepresentative data comprises selecting based on frequency of writeoperations.
 19. The computer-readable storage medium of claim 15 whereinselecting at least one full-size allocation unit of representative datacomprises selecting based on frequency of relocation operations.
 20. Thecomputer-readable storage medium of claim 15 comprising selecting a newreduced size allocation unit for compressed data based on changes inaverage compressed size of full-size allocation units of data.